Cream of the Crop 3/Cream of the Crop 3.iso/comm/aprs30_2.zip/README.OPS

Text File | 1993-11-12 | 10KB | 149 lines

                        APRS OPERATIONS NOTES

   The following discussionm may help you to understand the finer points of
operating an APRS net.  It covers the two categories of operations.  Routine
and Special event.  Also read the section on OBJECTS since the information
there applies to both cases.  The advantages of APRS are many, but there is
a price.  Since APRS uses a fixed digipeater path sometimes different for
different stations depending on geographic location, there is a lot of
duplication of on the air packets.  This assures that all stations in the net
are maintained up to date, but also proves to be wasteful during intense
operator-to-operator QSO's where this point-to-point traffic is still being
unnecessarily broadcast to all stations in the net.  For this reason, APRS
operators should always consider using TNC TALK mode (connected) to do
intense one-on-one keyboard QSO's.  Especially if a direct connect without
using APRS digipeaters is possible!  See README.MCM for lessons learned at the
Marine Corps Marathon.  Many imporvements were made in version 2.13 to reduce
the APRS packet QRM by at least a factor of four as a result!

ROUTINE OPERATIONS:  The APRS default digipeater path of RELAY is ok for a few
users starting up an APRS net, but you will soon need to focus on a few good
stations to serve as WIDE area digipeaters.  Once you put up a few good wide
area digipeaters with the generic ALIAS of WIDE, the coverage of the network
can be extended significantly.  It is important to keep generic WIDEs well
separated (40 miles or more over smooth terrain) to minimize duplicate repeats.
Most users should be able to hit at least one of these WIDEs.  All users must
understand that they are responsible for setting their outgoing VIA path so
that their packets hit the intended area of interest.   Unlike normal CONNETED
protocols which return ACKS via the reverse path of incomming packets, APRS is
an unconnected broadcast protocol only and each stations packets will only go
via the outgoing path set up by that station.  In version 2.13, if your
station receives a duplicate APRS MSG packet more than 4 times, it gives you a
beep and an alert that your ACK's are probably not being heard by the other
station and that you should check your outgoing VIA path.

    Those stations between WIDE area digipeaters only need to use the single
hop of WIDE and their packets will go in both directions.  Stations that can
only hit one WIDE area station may set the path of WIDE,WIDE without any
conflicts.  Paths of WIDE,WIDE,WIDE should be avoided for routine operations
because it folds back on itself.  The same area can be covered by using
WIDE,WIDE,W3XYZ where the unique call of the third digipeater is specifically
specified.  If you think about it, stations at the end of an area can specify
a pretty long string of digipeaters since the path is linear.  Stations in
the middle can only specify a symetrical double hop with WIDE,WIDE before
they have to begin favoring one direction or another with unique calls.

CAUTIONS ABOUT APRS MESSAGES:  Remember that the general condemnation of
multiple digipeater hops in the packet community applies only to connected
protocols.  This is because the probability of success goes down drastically
because all ACKS must be successfully returned or all packets are repeated.
This is generally NOT a problem with APRS since only UI frames are used, and
there are no acks.  HOWEVER, APRS one line MSGS are ACKED and if you
do a lot of one-line messages between operators, you will experience the
gradual buildup of collisions due to the quasi-ack process built into APRS
for operator messages).  But operator messages are a secondary function of
APRS, and should not be used as a primary means of passing traffic!  One
further caution, since APRS suspends all packet processing while waiting for
the operator with a BLUE-BOXED prompt, never linger in a blue-box prompt.
The SEND command is a BLUE-BOXED prompt and should not be left un-answered!

OBJECTS:  As noted previously, anyone may place an object on the map and all
other stations will see it.  In their systems, on their P-list, the object's
position report will be marked with the last three letters of the station
that is currently uplinking that position to the net.  A neat feature of APRS
is that any station that has more current information on the location of that
object can update its position by hooking, moving the cursor, and then
hitting the insert key.  Now this new station begins uplinking the new posit,
and all stations, will update their P-list entry for that object INCLUDING
THE ORIGINAL UPLINK STATION!  The new position overwrites the old one so that
the original station will now no longer uplink it.  This came in handy during
hurricane tracking.  Who ever had information on the latest NWS EMILY
position, uplinked it and everyone then always saw the latest storm track
without anyone in the net being dependent on any one station for updates!

     Once objects are transmitted on to other station map screens, they will
remain there until that operator deletes them.  Even if the original station
stops sending the object position, it will remain there forever.  So each
station should delete old objects on his screen as desired to keep the picture
clear.  When I get time, I hope to add a DELETE-OBJECT capability, so that
the originator of an object, can delete his objects from all screens...


SPECIAL EVENTS:  Let me use the Cycle Across Maryland (CAM) bike tour as an
example of a special event which took a lot of daily APRS coordination.  We
had two of three relief vehicles configured with GPS packet transponders.
These were assembled in cake pan enclosures for duct-taping to the roof of
any vehicle.  The uside down cake pans are reasonably aerodynamic and support
both the GPS antenna and a 19 inch 2 meter whip.  A single power cable
extended down the windshield and was clipped directly to the vehicle battery.
The package could be moved to another vehicle in about five minutes.  The
cake pan included only a walkie talkie transmitter at about the one watt
level.

    Since we only have two WIDE area APRS digipeaters in the state, and the
CAM tour never went near them, we were dependent on home stations all across
the state to serve as digipeaters for the event.  The GPS packages were set
to digipeat via the WIDE,WIDE path.  By setting the alias of all home
stations along the route to be WIDE, the vehicles were never beyond range of
at least one WIDE station.  Since the outgoing GPS packets were set up for
WIDE,WIDE, the second digipeat was always picked up by one of the existing
permanent WIDE digipeaters so that stations throughout the state could see
the position of the one watt GPS units!  We were looking for home stations
about every 10 miles.  Of course, as soon as a station was passed and was not
longer in direct contact with the GPS units, it was IMPORTANT to remove the
WIDE alias to minimize duplicative repeats.  For this seven day event, home
stations were organized on a nightly basis.  Assigned stations would be WIDE
for a whole day so that operators did not have to be home during working
hours.

     As an added technique, we also set up both GPS units with the alias
of WIDE so that they would also help digipreat each other along the trail.
The disdavantage of this technique was evident as both vehicles returned to
the evenings command post (also WIDE) and you had three WIDE digipeaters in
100 yards of each other!  It was noisy within local simplex range of that
site, but stations all over the state still saw the packets via the permanent
WIDE digipeaters.  Eighty percent of the home stations used as WIDE
digipeaters had never even heard of APRS.  They simply heard about the need
for home packet stations and only had to change their ALIAS (and frequency)
as directed by local announcements posted on all area BBS's.

     The event was an exciting success!  Occasionaly there were not enough
HAM voice operators per day to have HAMS in all of the relief vehicles.  When
ever a shortage occurred, the HAMS were removed from the GPS vehicles and
assigned elsewhere.  The location of the GPS vehicles were always known by
net control via the APRS system so the need for a HAM rider was not necessary
and in fact, only took up valuable space.  Whenever voice communications were
needed with the GPS relief vehicle, a mobile HAM was directed to the location
indicated on the APRS screen.

EMISSION CONTROL:  If there are only a few APRS stations involved in an event
but there are lots of APRS observers on frequency, then the observers can set
their transmitter off using the CTRL-X command.  That way they minimize the
QRM on channel.  While the transmit function is disabled with CTRL-X, a one-
time transmission can be forced each time the T key is pressed.  The T key
enables one cycle of APRS transmission which may contain up to four packets
containing your Beacon, Position, Objects, or Messages.

LOAD SHARING:  Since any station can take over reporting of any objects, one
approach is to let only one station hook every symbol that comes in and then
he becomes the reporting repsonsibility.  The original station that uplinked
the report in the first place will fall silent when it sees the report
comming from the designated Net Control station.  This way all positions are
reported by only one station on frequency, although all other stations can
still update the positions as needed.  Remember that the last station to
report the position of an object will be the one that continues to report it!

MARINE CORPS MARATHON:  See the README.MCM for details and lessons learned
using APRS at the Marine Corps Marathon on 24 October in Washington DC.